微前端在不同 Repository 架構中的 CI/CD 策略

專案架構

這個議題又可以分以下幾種來說明

• Monolith Repo
• Mono Repo
• Multi Repo

在不同的專案架構下也有不同的策略可以執行

Monolith Repo

一般最常見的架構就是 Monolith 專案結構，沒有去分多個 package，這時純粹只是 shared 不同的資料夾進行共享，打包出來也會是不同的 entry point。同常此時規模通常不大，也不太好做分散式部署，微前端需求還未明朗。當分模塊打包時，你很難用 module federation 去執行共用。所以此時 CI/CD 不太會去做到微前端，真要做依然還是會統一執行腳本，並且會在 CD 完成後再分派部署到多個服務上。如果有極為特殊情況，才會單獨為每個分塊作客製化腳本去處理。

Mono Repo

當專案開始採用 MonoRepo 之後，每個功能塊已經被明確用 package 進行切分，每一組模組有更明確的依賴系。這個時候專案的專案體積也日漸增大，跑個 CI 可能要 5 ~10 分鐘，上 CD 甚至可能要 10~15 分鐘，各方面開始覺得沈重。這時可以在 CI/CD 腳本上加上 git diff 的判斷，依照 PR 與目標的變動性評估變化的規模，去優化實際要檢查的檔案規模。經驗上其實以每個 package 作為單位切分點就有很不錯的效果，既能有效節約 CI 的時間，也不會過度處理腳本初始化。

Multi Repo

當專案足夠大時，連 MonoRepo 都難以管理，這時架構就會朝向 MultiRepo，逐漸的把專案拆開成獨立的 Repo。當每個 Repo 有一定的依賴關係時，會採用明確的版本去做依賴，更不用擔心發布時造成損毀。當然測試的整合性也會變差，每個 Repo 都會 CI/CD 腳本，共用性和特性差異上相當差。這時開始需要用一層專門處理 CI/CD Abstract Layer Repo 作為腳本中心，統合管理這些 Repo，而每個 Repo 只需要負責去觸發這個腳本工作。

部署設計

通常在發布前端的靜態資源時，都會直接使用 Nginx 容器作為發布載體，使用便捷也簡單，邏輯也清晰易拆分。但問題就在十分浪費資源硬體資源，不過是少少的靜態檔案就會需要佔據大量的容器資源。此時就可以把靜態資源轉移到 Object Storage 上去發布，可以更近一步優化。